Release 1.1 is the first major upgrade of Oberon/F. It corrects several errors of Release 1.0, adds some new features, streamlines a couple of existing features, and provides more robust error handling. Furthermore, it has a more systematically constructed documentation, as well as many new examples.
Controls, guards, and notifiers
The most important area where improvements have been made is in the area of controls and dialogs. There now is support for the important list box, selection box, and combo box controls, as well as a group control which allows to visually combine related controls.
Control guards now make it possible to adapt a control's state as a reaction to a state change in another control, e.g. when a text field becomes empty, a button may be disabled.
Control notifiers are a new feature which make it possible to add behavior to controls, e.g. notifier commands may be called when a command button is pressed or released, or when the selection in a selection box is changed.
Commands with parameters
Control guard commands, as well as menu guards, have been made more convenient by giving them parameters. Traditionally, Oberon commands have been parameterless procedures. In Release 1.1 however, commands may have parameters. This made it possible to eliminate the "pseudo-commands" of Release 1.0, i.e. commands with parameters which were only known to the command interpreter (i.e. to the Dialog.Call procedure).
To see the typical use of parameterized commands, look at the menu definition text (item "Menus" in menu "Info"), or consult the documentation of module StdCmds.
Several of the (previously pseudo-)commands now support a portable file name syntax. In order to be compatible with the World-Wide-Web notation, the Unix path name syntax was chosen.
Incremental updates and electronic distribution
In order to allow incremental upgrades in the future, the Oberon/F core is not linked anymore, i.e. each module (except for a few kernel modules) can be updated individually, simply by replacing its code file. A new tool (StdCoder) was added which allows to distribute binary files via ASCII channels, e.g. via Internet mails. The encoding is chosen such that it is robust and survives transmission via all mail software known to the developers.
An extensible conversion mechanism
The file conversion facility of Release 1.1 is much improved over its predecessor, and made public such that anyone can write his or her own file import or export commands, e.g. to import RTF texts or to export text in HTML format. See module Converters.
Improved texts, and new tools
The text subsystem has improved rulers. They make it possible to leave right margins unspecified, which means that the text view's right border defines the margin instead. The line breaking of such a text adapts to every change of the view's size, a useful feature for embedded text views.
The text model now lets Unicode (16-bit) characters to be stored in texts. On platforms which support Unicode fonts (currently this is only Windows NT) it is now possible to use foreign language characters, a variety of mathematical symbols, etc.
Text controllers have been modified to make text stretches active by inserting a pair of link views (of the new module StdLinks) into the text. If the text is in mask or in browser mode, a click on the text stretch between the delimiting views invokes an arbitrary command stored in one of the views. This makes it possible to implement look-up commands, e.g. text runs looking and behaving like World-Wide-Web links, or acting like command buttons, etc. The browser mode is a new text controller mode which makes it possible to use link views as described above, but simultaneously select text (i.e. find & replace works in this mode, and text stretches can be copied out from such texts). Text cannot be edited, however. This is the recommended mode for documentation texts.
Fold views (module StdFolds) allow to fold text into smaller text pieces, e.g. to collapse a paragraph into its headline.
A new "wizard" automatically creates source code templates for typical view implementations, thus simplifying view programming (module StdSubTool).
The Oberon/F core
The Oberon/F core module interfaces have been slightly extended or streamlined. Domains have become simpler, while module Math has been much expanded. Module Dialog was moved down to the basic Oberon/F library modules. The type-bound procedures of a Dialog.Interactor have been replaced by more flexible global procedures. The procedures for reading, opening, and writing views in module Views have been generalized and are more orthogonal now.
Most symbol files, even of private modules, are now distributed. The use of private modules is not recommended and no support or documentation for them is provided, however.
Module Stores has been simplified, by eliminating the procedures Stores.Store.Clone, Stores.Store.Init, and the flag Stores.Store.init. Models have received two new interface procedures, namely Models.Model.CopyAllFrom and Models.Model.InitFrom. In Views, the type-bound procedure Views.View.CopyModelFrom has been replaced by the global procedure CopyModel, and the new procedure Views.View.InitModel was added.
Documentation and Obx
The documentation has been extended and is now better structured, e.g. there is now a docu file for each top-level module. Some previously private modules are now documented, e.g. Containers, Properties, Converters, Controls.
The examples collection has been extended and is now better structured as well. There are new examples such as a mail merge command, an interesting game, a calculator, and many more. Like the rest of the documentation, the examples collection ("Oberon by Example", or Obx) can be accessed conveniently via the new hyperlinks.
User interface aspects
The user interfaces of both the Windows and the Macintosh have been improved further. Some rarely used commands have disappeared (Log Settings..., Paste to Window), some new menus (Tools) and menu items (View State, Edit Mode, Mask Mode, Layout Mode) have been added, and some of the existing menu items have been adapted to more closely adapt to the (evolving) user interface guidelines of their respective host platforms.
The Windows version now sports the 3-D Windows look of Windows 95. The Macintosh version menus have been made similar to the standard OpenDoc menus; as currently specified by Apple. The planned migration of Oberon/F to OpenDoc (due in phases sta
. Domains.Domain.init, Domains.Domain.shared, Domains.shared, Domains.exclusive have disappeared.
Dialog
In order to make more powerful controls possible, new interactors have been added (Dialog.Combo, Dialog.LargeSet), and the procedures Dialog.Update and Dialog.CheckGuards have been introduced. They replace the Notify and CheckGuards procedures of Release 1.0 interactors. Replace
interactor.Notify by Dialog.Update(interactor)
interactor.CheckGuards by Dialog.CheckGuards.
In general, a sequence of one or more calls of Dialog.Update should be followed by one call to Dialog.CheckGuards.
Standard file dialogs have been made simpler and more powerful, by providing separate interfaces for standard file dialogs for Oberon/F documents and for standard file dialogs for other files.
If you've used Dialog.GetIntSpec or Dialog.GetExtSpec to manipulate documents that contain views, then you should adapt your code such that Dialog.GetIntSpec and Views.OldView are combined, or Dialog.GetExtSpec and Views.RegisterView, respectively:
Dialog.GetIntSpec(type, stationary, loc, name) by loc := ...; name := ...; conv := NIL;
v := Views.Old(Views.ask, loc, name, conv)
Dialog.GetExtSpec(default, type, stationary, loc, name) by loc := ...; (* e.g. same as result of Views.Old *)
name := ...; (* e.g. same as result of Views.Old *)
conv := NIL; (* or same as result of Views.Old *)
Views.Register(v, Views.ask, loc, name, conv,
res)
On the other hand, if you've used Dialog.GetIntSpec or Dialog.GetExtSpec to manipulate files directly, then make the following replacements (i.e. eliminate stationary):
Dialog.GetIntSpec(type, stationary, loc, name) by Dialog.GetIntSpec(type, loc, name)
Dialog.GetExtSpec(default, type, stationary, loc, name) by Dialog.GetExtSpec(default, type, loc, name)
The internal variables Dialog.background and Dialog.maxBorderSize have disappeared.
The global variable Dialog.par and procedure Dialog.Disable are not necessary anymore, since guard commands now have parameters. Replace
PROCEDURE MyGuard;
BEGIN
IF ... THEN Dialog.Disable END
END MyGuard;
PROCEDURE MyGuard (par: Dialog.Par);
BEGIN
IF ... THEN par.disabled := TRUE END
END MyGuard;
Fonts
Fonts.Directory.System has disappeared, you should use Fonts.Directory.Default instead.
Ports
The new procedure Ports.RGBColor constructs a color out of its red, green, and blue components.
Stores
The new procedure Stores.SameType checks whether two stores have exactly the same type.
Views
Views.Frame.target has been replaced by Views.Frame.front.
The procedure Views.View.InitModel has been added. Views with models should extend this procedure.
The new procedure Views.HandlePropMsg should be used in containers, instead of calling an embedded view's HandlePropMsg directly. The semantics remain the same, but traphandling is made more robust.
The new procedures Views.OldView, Views.OpenView, and Views.RegisterView have been added as shortcuts for Views.Old, Views.Open, and Views.Register. Make the following replacements (with conv: Converters.Converter):
Views.Open(view, NIL, "") by Views.OpenView(view)
Views.Open(view, loc, name) by conv := NIL;
Views.Open(view, loc, name, conv)
See also the discussion of Dialog.GetIntSpec and Dialog.GetExtSpec above.
(.txt)